Fix timing issue where a disconnected node is being requested & returned#362
Fix timing issue where a disconnected node is being requested & returned#362stevschmid wants to merge 2 commits intorubycdp:mainfrom
Conversation
Previous solution had still some leeway for timing issues, leading to intermittent failing specs (albeit rarely)
|
I am facing a similar issue in my tests. It will occasionally fail. However never when I do a While I only did very minimal testing I was not able to reproduce this bug with this patch. |
|
While separating Ferrum and Cuprite I had only one idea — Ferrum should be very simple and straightforward. For example you want to get a node that's fine here it is, Ferrum doesn't care if node is visible/disconnected or disappear in the DOM while still being exist in ruby world. Cuprite on the other hand should handle that correctly, because if you have a node you might click on it and besides clicking we should scroll node into viewport, check if element is overlapped by other elements and so on. |
3 participants
This PR fixes the issue outlined in rubycdp/cuprite#239.
I fixed this initially by adding a
node.isConnectedcheck toCuprite.isVisible, but after digging a bit deeper, it seems that the node get disconnected between thecallfor_cuprite.findand itshandle_response. In this case we request a node viaDOM.requestNodewhich is not connected to the document anymore and does not seem to get obsolete (subsequent commands such as #visible? never raiseNodeNotFoundError).I'm not sure this is the right place, maybe adding a disconnected check in Cuprite
Nodemight be a bit less invasive. Please tell me what you think.